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Abstract  —  Modern  IS R1  /IS TAR2  networks  comprise 
a  very  diverse  and  disparate  set  of  asset  types  and  net¬ 
working  technologies,  which  provide  a  unique  set  of  chal¬ 
lenges  in  the  areas  of  sensor  identification,  classification, 
interoperability  and  sensor  data  sharing,  dissemination 
and  consumability.  This  paper  presents  the  ITA  Sensor 
Fabric,  developed  as  part  of  the  International  Technol¬ 
ogy  Alliance  (ITA)  in  Network  and  Information  Science, 
a  middleware  infrastructure  that  addresses  these  chal¬ 
lenges  by  providing  unified/universal  policy  controlled 
access  to,  and  management  of,  ISR/ISTAR  networks. 
The  ITA  Sensor  Fabric  spans  the  network  from  com¬ 
mand  and  control,  through  forward  operating  bases,  and 
out  to  mobile  forces  and  fielded  (both  mobile  and/or 
fixed)  sensors  in  the  area  of  operations.  This  paper  also 
presents  a  use  case  scenario  developed  in  partnership 
with  the  U.S.  Army  Research  Laboratory  (ARL)  and  de¬ 
ployed  in  ARL’s  Wireless  Emulation  Laboratory  (WEL), 
that  demonstrates  the  ITA  Sensor  Fabric  applicability  to 
coalition  operations. 

Keywords:  Sensor  networks,  middleware,  fabric,  pol¬ 
icy,  ISR,  ISTAR. 

1  Introduction 

The  diversity  of  sensors  and  networking  technologies 
commonly  used  in  fielded  sensor  networks,  particularly 
in  a  coalition  context,  provide  a  unique  set  of  challenges 
[1]  in  several  areas  including: 
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1  Intelligence,  Surveillance,  and  Reconnaissance. 

2 Intelligence,  Surveillance,  Target  Acquisition,  and  Reconnais¬ 
sance. 
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•  Sensor  identification  and  discovery. 

•  Sensor  access  and  control. 

•  Sensor  data  consumability. 

•  Policy-based  interoperability  and  trust. 

The  ITA  Sensor  Fabric  (or  Fabric)  is  an  evolving  mid¬ 
dleware  infrastructure,  developed  as  part  of  the  Interna¬ 
tional  Technology  Alliance  in  Network  and  Information 
Science  [2],  that  addresses  these  challenges  by  provid¬ 
ing  unified  access  to,  and  management  of,  sensor  net¬ 
works.  The  Fabric  is  designed  to  simplify  the  develop¬ 
ment  and  operation  of  sensor  network  solutions,  specif¬ 
ically  those  concerned  with  how  sensors  are  attached, 
discovered,  and  utilized.  In  this  paper  we  describe  the 
Fabric,  and  its  application  to  a  simulated  representative 
coalition  operation  scenario. 

The  Fabric  spans  the  network  from  the  data  centre 
to  deployed  sensors  and  mobile  personnel.  It  tracks  the 
sensors,  nodes,  and  users  of  the  sensor  network  facili¬ 
tating  universal  access  to  sensor  data  from  any  point, 
and  maximising  its  availability  and  utility  to  applica¬ 
tions  and  users.  The  Fabric  is  an  extensible  platform. 
Its  plug-in  architecture  allows  new  functions  (such  as  fil¬ 
ters,  transformations,  policies,  security,  and  event  detec¬ 
tion  algorithms)  to  be  deployed  into  the  sensor  network 
and  selectively  applied  to  sensor  messages  en  route  to 
the  user. 

The  Fabric,  in  addition  to  its  use  with  fielded  sensor 
networks,  can  also  be  used  as  a  research  and  development 
tool  that  bridges  the  worlds  of  simulators  and  fielded  sys¬ 
tems.  Its  plug-in  architecture,  sensor  data  record  and 
playback  capability,  sensor  simulation,  and  performance 
measurement  features  make  it  ideal  as  a  research  plat¬ 
form  that  offers  a  high  degree  of  fidelity  with  fielded 
systems  (indeed  it  is  such  a  system).  Many  technologies, 
techniques,  and  algorithms  can  be  easily  integrated  with 
the  Fabric  providing  significant  opportunities  for  exper¬ 
imentation,  evaluation,  and  an  accelerated  route  to  use 
in  the  field. 
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First  and  foremost  the  Fabric  exists  to  provide  sensor 
network  clients  (i.e.,  the  final  consumers  of  sensor  data) 
with  controlled  access  to  sensor  network  assets.  At  a  fun¬ 
damental  level  each  sensor  can  be  viewed  as  a  source  of 
one  or  more  data  feeds.  The  Fabric  provides  clients  with 
the  means  to  discover,  control,  and  access  the  data  feeds 
that  they  require  to  complete  their  tasks  [3] .  Clients  can 
be  individuals  accessing  the  sensor  network  via  one  or 
more  applications;  they  can  also  be  software  processes 
(for  example,  agents  and  services)  that  require  access 
to  sensor  data  to  complete  a  higher-level  task  that  will 
ultimately  provide  value  to  a  human  user.  Clients  can 
be  located  at  any  point  on  the  Fabric.  They  will  often 
be  monitoring  sensors  from  a  workstation  in  a  command 
and  control  centre.  Equally,  they  might  be  co-located 
with  (or  close  to)  the  sensors  themselves.  For  example, 
and  in  a  commercial  setting,  an  engineer  who  needs  to 
monitor  sensor  output  whilst  performing  maintenance  in 
an  industrial  plant. 

In  the  remainder  of  this  paper  we  describe  the  Fabric 
and  its  applications  in  more  detail.  Section  2  describes 
the  software  architecture  of  the  Fabric  and  its  various 
components,  as  well  as  providing  a  discussion  on  extend¬ 
ing  its  capabilities.  Section  3  details  the  application  of 
the  Fabric  in  a  simulated  case  study,  which  provides  a 
motivating  example  for  the  use  of  the  Fabric  in  an  ad-hoc 
networking  environment  involving  coalition  operations. 
To  complete  the  paper,  concluding  remarks  are  given  in 
Section  4,  and  directions  for  further  work  in  Section  5. 

2  The  ITA  Sensor  Fabric 

The  ITA  Sensor  Fabric  is  a  two-way  messaging  bus  and 
set  of  middleware  services  connecting  all  of  the  network’s 
assets  to  each  other  and  to  users.  The  Fabric  leverages 
a  publish/subscribe  messaging  model  with  multi- hop  ca¬ 
pabilities,  and  ensures  that  messages  are  propagated  effi¬ 
ciently,  without  duplication,  and  with  the  minimum  use 
of  valuable  network  bandwidth.  Through  the  use  of  the 
Fabric,  an  ad-hoc  network  of  communicating  nodes  can 
be  viewed  as  a  SOA3-style  service  bus,  with  transparent 
handling  of  connections  and  routing  (Figure  1). 

A  Fabric  node  is  a  node  on  the  sensor  network  that 
runs  the  following  software  stack: 

•  An  instance  of  a  message  broker  [4]. 

•  An  instance  of  a  Fabric  Manager. 

•  An  instance  of  a  Fabric  Registry. 

Clients  also  attach  to  Fabric  nodes,  consuming  both 
local  data  and  data  received  from  other  Fabric  nodes  in 
the  network  (although  in  both  cases  the  client’s  interface 
to  the  data  is  via  the  bus).  The  Fabric  Manager  and 
Fabric  Registry  processes  are  described  in  more  detail 
below. 

3  Service  Oriented  Architecture 
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Figure  1:  The  abstraction  of  the  interconnections  within 
the  sensor  network  provided  by  the  Fabric  bus. 


When  requesting  data,  clients  simply  ask  their  local 
Fabric  Manager  for  feeds  from  one  or  more  deployed  as¬ 
sets,  requiring  no  knowledge  of  the  structure  of  the  de¬ 
ployed  network  itself.  The  Fabric’s  handling  of  connec¬ 
tions  and  routing  means  that  a  deployed  network,  such 
as  that  seen  in  Figure  2,  may  be  viewed  using  the  logical 
bus  of  Figure  1  by  the  network’s  end  points,  reducing 
the  complexity  of  data  acquisition  and  dissemination. 


2.1  Publish/Subscribe  Messaging 

The  ITA  Fabric  builds  upon  the  publish/subscribe 
messaging  pattern,  which  is  well  known  and  well  estab¬ 
lished  in  Enterprise  Application  Integration.  In  this  sec¬ 
tion  we  give  an  introduction  to  the  basic  architecture 
and  benefits  of  publish/subscribe  messaging. 

Publish/subscribe  messaging  provides  a  one-to-many 
distribution  mechanism  that  utilizes  a  central  hub  or 
broker  through  which  all  messages  pass.  Thus  a  single 
message,  published  from  a  device  on  a  low  bandwidth 
and/or  high-cost  network  to  a  message  broker,  could  be 
efficiently  distributed  to  a  large  number  of  subscribers. 
The  message  broker  administers  the  message  distribu¬ 
tion  process  using  a  topic-based  approach.  It  receives 
subscription  requests  from  client  applications,  indicating 
the  topics  in  which  they  are  interested.  When  a  message 
is  received  from  a  publisher  on  a  topic  that  matches  one 
or  more  of  the  subscriptions,  the  broker  sends  a  copy  of 
that  message  to  each  registered  subscriber. 

The  most  powerful  aspect  of  broker-based  pub- 
lish/subscribe  messaging  is  the  decoupling  of  publishers 
from  subscribers,  as  depicted  in  Figure  3.  Clients  only 
have  to  deal  with  their  connection  to  the  broker;  they 
have  no  knowledge  of  the  source  or  destination  of  the 
messages,  unless  it  is  specifically  included  in  the  content 
of  the  message. 
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Figure  2:  The  topology  abstracted  by  the  Fabric  bus. 


2.2  The  Fabric  Messaging  Bus 

The  Fabric  is  a  two-way  messaging  bus  that  connects 
assets  and  clients  on  a  sensor  network.  The  connection 
is  not  direct;  it  is  decoupled  via  the  publish/subscribe 
paradigm.  That  is  to  say,  producers  of  data  (sensors) 
publish  to  the  bus,  and  the  consumers  (clients)  then  sub¬ 
scribe  to  the  bus  in  order  to  receive  the  sensor  data.  The 
data  itself  is  identified  on  the  bus  using  a  globally  unique 
topic  name  and,  as  such,  every  data  feed  from  every  sen¬ 
sor  is  uniquely  identifiable. 

Not  only  sensors  publish  data  onto  the  bus;  soft¬ 
ware  services  that  aggregate,  fuse,  transform,  and  fil¬ 
ter  sensor  data  will  also  publish  their  output  using  the 
same  technique.  Furthermore,  the  Fabric  uses  the  pub¬ 
lish/subscribe  model  not  only  to  connect  publishers  with 
subscribers,  but  also  to  send  control  and  management 
messages. 

Sensor  networks  consist  of  a  set  of  interconnected 
nodes.  Typically  there  is  not  a  direct  network  con¬ 
nection  between  each  node,  and  so  the  Fabric  provides 
multi- hop  communication  capabilities.  Poorly  connected 
nodes  at  the  edge  of  the  network  can  fully  participate 
on  the  Fabric  bus  giving  Fabric  users  a  single,  fully  con¬ 
nected,  system.  The  distributed  publish/subscribe  capa¬ 
bility  is  implemented  using  interconnected  brokers,  one 
per  Fabric  node,  with  the  message  propagation  handled 


by  the  Fabric.  Every  effort  is  made  to  route  messages 
efficiently,  without  duplication,  and  with  the  minimum 
use  of  valuable  network  bandwidth.  To  achieve  this, 
the  Fabric  Manager  employs  an  algorithm  to  determine 
whether  messages  have  been  altered  by  the  application 
of  a  plug-in,  and  to  combine  those  messages,  destined 
for  separate  clients,  that  are  identical.  This  reduces  the 
network  bandwidth  usage  when  the  transformed  message 
is  re-published  to  the  next  node(s)  en  route  to  the  sub¬ 
scriber  (s),  and  the  process  then  begins  again  on  the  next 
node  in  the  journey. 

At  the  pure  messaging  layer  the  communication  is 
anonymous.  In  a  distributed  messaging  fabric,  this 
means  that  a  publishing  sensor  node  or  subscribing  ap¬ 
plication  need  only  be  concerned  with  the  connection  to 
its  local  message  broker.  The  Fabric  transparently  or¬ 
chestrates  the  broker-to-broker  communications  between 
the  sending  and  receiving  applications. 


Figure  3:  Decoupling  publishers  from  subscribers. 

2.3  The  Fabric  Manager 

As  the  main  Fabric  service  running  on  a  node,  the  Fab¬ 
ric  Manager  has  wide  ranging  responsibilities.  It  builds 
the  major  capabilities  of  the  Fabric  on  top  of  the  mes¬ 
sage  broker  (which  provides  the  actual  communications 
infrastructure)  and  the  Fabric  Registry  (which  is  respon¬ 
sible  for  storing  the  configuration  and  operational  status 
of  the  Fabric  infrastructure).  The  major  features  and 
functionality  provided  by  the  Fabric  Manager  are  as  fol¬ 
lows: 

•  Establishes  the  communication  channels  between 
nodes,  handling  the  routing  of  message  between 
publishers  and  subscribers  attached  to  the  bus. 

•  Tracks  the  operational  status  of  connected  sensors 
and  nodes,  and  in  the  future  will  register  local  data 
fusion  algorithms  as  intelligence  assets  with  the  Fab¬ 
ric  Registry. 

•  Provides  a  container  for  running  plug-ins,  in- 
network  information  fusion,  filtering,  and  other  al¬ 
gorithms. 
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•  Provides  the  point  from  which  the  capabilities  of  the 
Fabric  may  be  extended. 

2.4  The  Fabric  Registry 

Infrastructure  information  about  the  Fabric,  includ¬ 
ing  details  on  all  deployed  nodes  and  other  ISR/ISTAR 
assets,  is  recorded  in  the  Fabric  Registry.  As  new  as¬ 
sets  are  added  to  the  Fabric  they  are  automatically  in¬ 
cluded  in  the  Registry,  making  them  available  for  use 
by  all  Fabric  users.  The  Fabric  Registry  is  implemented 
as  a  database,  storing  information  about  the  currently 
deployed  infrastructure  in  a  number  of  tables  defining: 
asset  types,  asset  instances,  networking  and  routing  in¬ 
formation,  tasks  and  task  associations,  Fabric  users,  and 
Fabric  extensions. 

Four  database  tables  detail  the  physical  assets  de¬ 
ployed  on  the  Fabric:  nodes,  platforms,  sensors,  and 
feeds.  Each  of  these  tables  includes  details  such  as  type, 
physical  location,  operational  characteristics,  neigh¬ 
bours,  task  commitments,  and  current  operational  sta¬ 
tus  / availability,  along  with  a  human  readable  description 
of  each  asset.  Every  class  of  asset  (node,  platform,  sensor 
and  feed)  has  an  associated  table  describing  the  various 
types  known  to  the  Fabric.  These  types  form  a  hierarchy 
when  defining  individual  asset  instances:  platforms  are 
connected  to  nodes,  sensors  are  mounted  on  platforms, 
and  one  or  more  feeds  are  published  by  sensors.  An¬ 
other  group  of  related  tables  define  the  configuration  of 
the  plug-ins  and  extension  points  (i.e.,  application  de¬ 
fined  message  processing)  deployed  on  each  node,  with 
plug-ins  configured  either  to  be  applied  to  each  message 
passing  through  a  node,  or  to  be  applied  to  messages 
destined  for  specific  tasks  or  clients. 

Further  tables  define  tasks,  and  associations  between 
tasks  and  collections  of  sensors  and  nodes.  This  allows 
clients  to  subscribe  to  a  group  of  nodes  required  to  per¬ 
form  a  required  task  without  having  to  subscribe  indi¬ 
vidually.  The  database  also  maintains  a  table  describing 
which  clients  are  subscribed  to  which  tasks. 

Routing  information  is  also  defined  within  the  Reg¬ 
istry.  A  table  in  the  database  details  the  neighbours  of  a 
node,  including  how  those  two  nodes  are  connected,  and 
whether  the  connection  is  currently  active.  One  or  more 
routes  between  two  nodes  may  then  be  described  includ¬ 
ing  the  individual  hops  in  the  route,  along  with  the  cost 
associated  with  each  hop.  This  information  may  then 
be  used  to  choose  the  route  for  messages,  depending  on 
criteria  defined  by  the  subscribing  clients,  for  example  to 
minimize  the  total  cost  to  the  network  for  transmitting 
the  data. 

The  current  development  version  of  the  Fabric  employs 
a  distributed  Registry  implemented  using  the  Gaian  dis¬ 
tributed/federated  database  [5],  also  developed  under 
the  ITA  program.  GaianDB  is  an  extension  to  Apache 
Derby  [6]  whose  principal  feature  is  its  ability  to  auto- 
nomically  discover  and  federate  other  GaianDBs,  usung 


a  scale-free  algorithm.  Its  connectivity  model  is  biologi¬ 
cally  inspired  in  that  it  strives  to  minimize  network  di¬ 
ameter  and  maximize  connections  to  the  fittest  nodes. 
GaianDB  advocates  a  flexible  “store  locally,  query  any¬ 
where”  (SLQA)  paradigm. 

By  implementing  the  Fabric  Registry  on  a  distributed 
database,  the  Fabric  has  in-built  resilience  to  network 
failures.  Should  a  portion  of  the  Fabric  become  discon¬ 
nected  then  the  fragments  can  continue  to  operate  as 
Fabric-islands  until  they  are  reconnected.  Each  Fabric- 
island  effectively  has  its  own  Fabric  Registry,  composed 
of  the  distributed  database  elements  that  are  still  con¬ 
nected,  meaning  that  the  node  information  stored  in  the 
visible  database  fragment  describes  exactly  those  nodes 
and  sensors  available  on  the  island.  Note  that  this  pro¬ 
cess  also  works  in  reverse,  for  example  when  two  fab¬ 
ric  islands  connect.  Optionally,  clients  can  choose  that 
subscriptions  to  message  feeds  be  persistent;  i.e.  when 
Fabric  islands  reconnect  the  interrupted  persistent  sub¬ 
scriptions  can  be  re-established. 

2.5  Sensors 

ISR/ISTAR  sensor  assets  publish  data  to  topics  in  a 
global  name  space.  They  have  no  notion  of  whom  or 
what  is  interested  in  their  data;  they  simply  respond  to 
received  control  messages,  or  requests  to  capture  read¬ 
ings  (and  publish  them  for  use  to  the  broker  on  their  lo¬ 
cal  Fabric  node).  Subscribers  may  be  client  applications 
or  software  agents  such  as  fusion  algorithms  or  filters. 
Subscribers  need  not  be  concerned  with  the  technical 
details  of  connecting  to  individual  sensor  nodes  to  re¬ 
trieve  data.  Instead  they  simply  subscribe  to  their  local 
broker  for  one  or  more  topics  in  the  global  name  space 
and  wait  for  the  data  to  arrive.  It  is  the  role  of  the  Fab¬ 
ric  to  establish  the  communication  channel  between  the 
two  brokers,  transparently  to  the  Fabric  end  points. 

A  Fabric  deployment  may  consist  of  physical  sensors, 
software  sensors,  or  any  mixture  of  the  two.  Software 
sensors  include  data  fusion  algorithms  that,  for  exam¬ 
ple,  aggregate  data  from  a  number  of  other  sensors  and 
publish  the  results  as  a  new  sensor  data  feed.  A  sub¬ 
class  of  software  sensors  are  simulated  sensors.  These 
are  software  applications  that  publish  generated  artifi¬ 
cial  sensor  readings,  or  replay  pre-recorded  sensor  data 
in  the  same  fashion  as  a  real  sensor.  By  default,  appli¬ 
cations  running  on  the  Fabric  are  unable  to  distinguish 
between  real  and  simulated  sensor  data4,  and  this  makes 
simulation  a  powerful  technique  for  creating  a  repeatable 
experimental  framework. 

Attaching  a  new  sensor  to  the  Fabric  requires  one  of 
the  following  configurations: 

•  The  sensor  runs  a  Fabric  Manager  and  broker,  al¬ 
lowing  it  to  connect  directly  to  the  Fabric. 

4 The  Fabric  does  provide  an  optional  mechanism  to  distinguish 
between  replayed  and  live  sensor  data. 
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•  The  sensor  runs  as  a  broker  client,  connecting  to  a 
more  capable  utility  node  in  the  Fabric  that  runs  a 
Fabric  Manager  and  a  broker. 

•  The  sensor  uses  an  alternative  communication 
mechanism,  such  as  a  direct  serial  connection,  to 
connect  to  a  utility  node,  whose  Fabric  Manager 
then  provides  a  bridge  to  the  broker. 

2.6  Extending  the  Fabric 

The  core  Fabric  provides  the  minimum  set  of  services 
required  to  implement  a  distributed  bus  framework.  Ad¬ 
ditional  capabilities  can  be  added  in  the  form  of  plug¬ 
gable  modules  (“plug-ins”).  Several  types  of  plug-in  are 
available,  each  intended  to  augment  a  specific  aspect  of 
the  Fabric’s  operation. 

2.6.1  Fabric  Extension  Points 

The  Fabric  is  designed  to  allow  major  functionality 
to  be  added  and  allow  base  functionality  to  be  replaced 
without  the  need  to  alter  the  core  messaging  bus.  The 
mechanism  used  is  the  Fabric  Extension  Point;  an  ap¬ 
proach  that  builds  upon  the  Fabric’s  core  message  pass¬ 
ing  functions.  All  inter- node  Fabric  communications  are 
message-based,  where  each  message  is  a  combination  of 
meta-data,  routing  information,  and  payload  data.  Fur¬ 
thermore,  each  message  is  given  a  type  associating  it 
with  a  specific  extension  point.  Note  that  extension 
points  represent  a  very  different  approach  from  the  Fab¬ 
ric  plug-in  model  that  we  will  describe  later:  exten¬ 
sion  points  provide  the  means  to  fundamentally  alter 
the  behavior  of  the  middleware  layer  to  accommodate 
new  techniques  and  methods;  plug-ins  primarily  deliver 
sensor  feed  subscription-based  services. 

Extension  points  have  access  to  the  core  Fabric  ser¬ 
vices  such  as  messaging,  the  Registry,  and  event  handling 
(for  example,  handling  sensor  disconnection  events).  As 
such  they  can  be  fully  integrated  into,  and  therefore  ex¬ 
tend,  the  operation  of  the  Fabric.  For  example,  the  stan¬ 
dard  sensor  subscription  service  provided  by  the  Fabric 
is  implemented  as  an  extension  point  and  can  therefore 
be  replaced  should  it  be  superseded  by  a  future  data 
dissemination  algorithm.  Furthermore,  this  technique 
ensures  that  the  Fabric  can  be  deployed  onto  nodes  in 
a  fully  modular  fashion,  ensuring  that  the  footprint  can 
be  optimized  to  suit  each  individual  target. 

2.6.2  Plug-ins  &  Message  Flow 

Messages  flowing  through  the  Fabric  are  available  for 
processing  at  each  node  on  their  journey.  Plug-ins  are 
small  code  modules  loaded  into  the  Fabric  Manager  that 
perform  processing  tasks  directly  on  messages  as  they 
flow  through  the  Fabric  from  publishers  to  subscribers. 

Three  types  of  plug-ins  are  automatically  applied  to 
messages  passing  though  a  Fabric  node:  node,  task  and 
client  plug-ins.  They  typically  perform  operations  such 
as  policy  enforcement,  filtering,  transformation,  logging, 


caching,  encryption,  or  routing,  and  their  application 
order  is  well  defined.  Node  plug-ins  are  applied  to  ev¬ 
ery  message  passing  through  the  node,  whereas  task  and 
client  plug-ins  are  applied  to  either  messages  for  a  spe¬ 
cific  task,  or  for  a  specific  client  associated  with  a  specific 
task,  respectively.  Since  the  node  plugins  are  applied  to 
every  message  regardless  of  task  or  client  subscription, 
we  can  reduce  the  processing  overhead  by  applying  each 
of  these  transforms  only  once  before  moving  on  to  the 
task  related,  and  lastly  the  client  related,  application 
paths. 

The  subscription  mechanism  manages  the  loading,  in¬ 
vocation  and  unloading  of  plug-ins,  based  on  their  asso¬ 
ciation  to  the  various  tasks  and  clients  registered  for  the 
incoming  message.  Figure  4  illustrates  how  messages  re¬ 
ceived  by  the  broker  on  a  Fabric  node  are  passed  to  the 
message  dispatcher,  which  applies  the  appropriate  plug¬ 
ins  based  on  the  currently  active  subscriptions. 


Figure  4:  The  flow  of  messages  through  a  Fabric  node. 


2.6.3  Fablets 

These  are  independent  programs  running  within  the 
Fabric  Manager,  with  all  the  freedoms  that  implies.  A 
typical  application  would  be  to  introduce  data  into  the 
Fabric  from  sensors  that  are  not  Fabric-aware,  or  data 
fusion  algorithms  that  require  access  to  more  than  one 
Fabric  feed. 
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2.7  Policy 

As  a  direct  result  of  the  collaboration  between  teams 
within  the  ITA  program,  the  Fabric  has  been  policy 
enabled  with  the  Watson  Policy  Management  Library 
(WPML),  allowing  authorization  and  obligation  policies 
to  be  enforced  on  messages  routed  between  nodes.  Fig¬ 
ure  5  illustrates  how  the  WPML,  along  with  the  plug-in 
architecture  of  the  Fabric,  enables  dynamic  deployment 
and  configuration  of  policies.  WPML  builds  on  a  widely 
accepted  policy  architecture  that  consists  of  four  basic 
elements:  a  policy  management  tool,  policy  repository, 
policy  decision  points,  and  policy  enforcement  points. 
WPML  employs  the  Common  Information  Model  Sim¬ 
plified  Policy  Language  (CIM-SPL)  [7]  [8]  and  the  Apache 
Imperius  policy  engine  [9]  to  specify  and  execute  declar¬ 
ative  rules  that  control  the  Fabric  message  flows. 


Figure  5:  WPML  architectural  overview. 

A  policy  is  a  condition-action  pair,  where  the  speci¬ 
fied  action  is  executed  if  the  condition  evaluates  to  true. 
Both  the  condition  and  action  can  be  defined  over  sensor 
data  (e.g.  the  bytes  of  an  image)  flowing  over  the  fab¬ 
ric,  or  over  metadata  describing  the  message  (e.g.  the 
organizational  affiliation  of  the  client  of  the  message). 

The  two  main  types  of  policies  are  authorization  (e.g. 
allow/disallow  access  to  a  sensor  data  feed)  and  obli¬ 
gation  (e.g.  downgrade  the  quality  of  the  sensor  data 
feed).  A  policy  repository  (PR)  stores  policies  that  are 
available  for  execution;  these  may  be  activated  or  deacti¬ 
vated  based  on  mission  requirements.  A  policy  decision 
point  (PDP)  is  a  logical  entity  which  evaluates  appli¬ 
cable  policies  in  the  repository  to  message  data  and/or 
metadata  and  returns  the  result  to  a  policy  enforcement 
point  (PEP),  a  logical  entity  that  is  tasked  with  mak¬ 
ing  a  decision,  e.g.  whether  or  not  to  grant  a  requesting 
client  access  to  a  sensor  data  feed.  The  PEP  requests 
the  decision  from  the  PDP  and  enforces  the  response 
received. 

Figure  6  illustrates  a  policy  used  to  implement  autho¬ 
rization  utilizing  client  affiliation  in  order  to  allow  or  dis¬ 
allow  access  to  high-resolution  imagery  by  U.S.  clients. 
The  example  policy,  when  activated,  has  the  effect  of 
downgrading  the  resolution  of  images  destined  to  U.S. 
affiliated  clients  by  50%. 


Import  Class 

com . ibm . watson . pml . pep . IAuthorizer : authorizer ; 

Import  Class 

com. ibm. watson. pml . fabric .runtime . IFabricMessageRuntime : f abricMessageRuntime ; 
Import  Class 

com. ibm. watson. pml . fabric .messaging. messages . IlmageMessage : imageMessage ; 

Strategy  Execute_All_Applicable ; 

Policy  { 

Declaration  { 

> 

Condition  { 

f abricMessageRuntime. getClientO  .getAff iliationO  ==  "UK" 

> 

Decision  { 

authorizer . allow () 

> 

}:1; 


Figure  6:  Policy  example. 

3  A  Coalition  Case  Study 

Civilian  and  military  coalition  operations  often  require 
that  two  or  more  organizations  form  an  ad-hoc  partner¬ 
ship  to  achieve  a  common  goal.  Each  participating  or¬ 
ganization  operates  under  a  set  of  inherent  restrictions, 
often  stated  as  a  set  of  security  and  legal  policies,  which 
might  have  to  be  combined  and  harmonized  across  the 
coalition.  One  of  the  key  aspects  of  coalition  operations 
is  the  reliance  on  fusion,  dissemination  and  sharing  of  in¬ 
formation  originated  from  an  ad-hoc  heterogeneous  and 
disparate  network  of  ISR/ISTAR  assets,  such  as  human 
intelligence,  unattended  sensors  (fixed  or  mobile),  data 
extraction,  fusion  and  correlation  providers,  and  network 
elements,  belonging  to  the  participating  coalition  orga¬ 
nizations.  The  dissemination  and  sharing  of  information 
in  such  environments  is  subject  to  a  set  of  organization 
specific  and  common  policies. 

The  scenario  for  this  case  study  involves  two  coali¬ 
tion  countries,  the  United  States  (U.S.)  and  the  United 
Kingdom  (U.K.).  Both  countries  will  participate  in  an 
ISR/ISTAR  operation  and  will  share  information  from 
their  specialized  sensors.  The  goal  of  the  operation  is  to 
identify,  locate  and  photograph  the  source  of  an  acous¬ 
tic  event,  and  make  all  the  sensed  data  (including  the 
imagery)  available  to  the  command  and  control  sites  of 
both  countries. 

The  U.S.  will  contribute:  a  set  of  unattended  ground 
sensors  (US:UGS)  [10]  capable  of  reporting  the  line  of 
bearing  (LOBR)  of  an  acoustic  event;  an  unmanned 
aerial  vehicle  (US:UAV)  to  provide  a  communications 
link  between  the  UGS  and  the  rest  of  the  Fabric; 
and  a  data  fusion  application  (US:Analytics)  to  fuse 
the  information  from  the  UGS,  calculate  and  publish 
the  most  likely  location  (US:LOCR)  of  the  acoustic 
event.  The  U.K.  will  contribute  a  high-resolution  camera 
mounted  on  an  unmanned  aerial  vehicle  (UK:Reaper), 
which  is  controlled/commanded  from  an  analytics  ap¬ 
plication  (UK: Analytics)  that  based  on  the  US:LOCR 
data  calculates  the  pan,  tilt  &  zoom  (PTZ)  commands 
(UK:CamCmd)  to  be  issued  to  the  camera.  Upon  re¬ 
sponding  to  the  PTZ  commands,  the  high-resolution 
camera  will  be  commanded  to  photograph  the  location 
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of  the  acoustic  event  and  make  the  imagery  (UKiImage) 
available  on  the  Fabric.  All  the  sensed  data  and  imagery, 
subject  to  policies,  is  made  available  for  consumption  to 
personnel  at  the  command  and  control  centers  of  each 
country. 

3.1  ARL  Wireless  Emulation  Lab 

For  this  case  study  we  deployed  the  scenario  on  a 
mobile  ad-hoc  network  (MANET)  emulation  environ¬ 
ment,  the  Wireless  Emulation  Laboratory  (WEL)  [11], 
hosted  at  the  U.S.  Army  Research  Laboratory  (ARL). 
The  WEL  provides  a  controlled,  repeatable  emulation 
environment  for  the  analysis  of  algorithms,  protocols, 
and  applications  pertaining  to  MANETs.  The  WEL  sup¬ 
ports  several  areas  of  research  including  coalition  war¬ 
fare,  network  science  and  network  security  for  MANETs. 
These  areas  of  research  are  facilitated  by  a  suite  of  soft¬ 
ware  tools  running  in  the  WEL  ranging  from  exper¬ 
iment/scenario  design  to  real-time  network  emulation 
and  visualization  (Figure  7). 

The  real-time  emulation  software  is  based  on  the  Mo¬ 
bile  Ad-hoc  Network  Emulator  (MANE)  originally  de¬ 
veloped  by  the  Naval  Research  Laboratory  [12].  MANE 
only  emulates  the  physical  and  MAC  layers  and  there¬ 
fore  offers  the  flexibility  to  support  a  broad  range  of  net¬ 
work  applications  such  as  the  ITA  Sensor  Fabric.  The 
software  controls  network  connectivity  between  nodes 
by  forwarding  and/or  corrupting  packets  according  to 
a  user  specified  mobility  and  propagation  loss  model. 
MANE  contains  multiple  propagation  models  including 
range-dependent,  free-space  loss,  and  Terrain-Integrated 
Rough-Earth  Model  (TIREM). 


Figure  7:  WEL  architecture  overview. 

To  implement  the  scenario  described  below  we  used 
four  unattended  ground  sensors  (UGS),  one  acoustic 
event  generator,  one  high-resolution  camera  and  five 
Fabric  nodes  deployed  on  the  WEL. 

3.2  Scenario  deployment 

Our  deployment  used  a  subset  of  the  WEL  consist¬ 
ing  of  25  test  nodes  in  a  wireless  mesh  configuration, 


five  of  which  hosted  Fabric  nodes,  analytic  applications 
and  policies.  Figure  8  illustrates  the  scenario  setup  and 
coalition  affiliations.  The  four  USiUGS  were  bridged 
to  node  AG  which  acts  as  an  auto  discovery  client. 
Node  A  (USiUAV)  is  a  Fabric  node  configured  as  an 
auto  discovery  server  and  provider  of  communication 
to  the  rest  of  the  Fabric.  When  the  four  USiUGS 
are  discovered,  they  are  added  to  the  Fabric  Registry 
and  their  USiLOBR  data  feeds  made  available  for  con¬ 
sumption  on  the  Fabric  bus.  Node  B  (US: Analytics), 
consumes  US:LOBR  data  provides  a  US:LOCR  feed. 
Node  C  (UK Analytics)  consumes  US:LOCR  data,  cal¬ 
culates  the  required  PTZ  parameters  and  publishes 
them  (UKiCamCmd).  Node  D  (UKiReaper)  consumes 
UK:CamCmd,  uses  the  PTZ  parameters  to  point  the 
camera  to  the  source  of  the  acoustic  event,  photographs 
the  site  and  makes  the  imagery  (UKiImage)  available  on 
the  Fabric.  The  U.S.  and  U.K.  command  and  control 
centers  (USiCmdCtrl  and  UKiCmdCtrl)  are  connected 
to  node  E  (USUK:CmdCtrl)  which  manages  and  controls 
the  dissemination  of  information  to  the  two  coalition 
partners.  At  the  command  and  control  center  of  each 
country,  a  Fabric  application  consumes  and  displays  the 
USiLOBR,  USiLOCR  and  UKiImage  data.  The  avail¬ 
ability  of  the  information  to  each  country  is  controlled 
through  access  policies  that  are  evaluated  by  the  Fabric 
at  the  USUKiCmdCtrl  node. 


4  Conclusion 

We  have  produced  the  basis  for  a  middleware  for  sen¬ 
sor  networks  which  facilitates  universal  access  to  intel¬ 
ligence  data  from  any  connected  point  on  the  network, 
which  monitors  and  controls  connected  assets,  and  has 
built-in  resilience  to  failures.  It  is  capable  of  spanning 
the  network  from  the  data  centre  to  deployed  sensors  and 
personnel,  and  maximising  the  availability  and  utility  of 
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intelligence  data  through  task  planning  services,  analy¬ 
sis  applications  (including  fusion  algorithms  and  agents), 
human  analysts,  and  mobile  personnel. 

Messages  are  propagated  efficiently  to  minimise  the 
use  of  valuable  network  bandwidth,  with  algorithms 
(such  as  data  fusion,  transformation,  filtering,  and  pol¬ 
icy  enforcement)  delivering  in-network  processing  of 
data.  The  capabilities  of  the  Fabric  can  also  be  ex¬ 
tended  through  programming  interfaces  (including  Web 
interfaces)  for  application  or  algorithm  development,  as 
demonstrated  by  our  example.  The  Fabric  Registry  pro¬ 
vides  management  services  for  Fabric  assets  by  tracking 
nodes,  data  sources  (hardware  assets  and  software  ser¬ 
vices),  users,  tasks,  and  deployed  algorithms;  and  also 
managing  the  visibility  of,  and  access  to,  intelligence 
data  feeds.  These  features  make  the  Fabric  useful  both 
in  real  network  deployments  and  as  a  tool  for  simula¬ 
tion  and  research;  the  current  development  version  of 
the  Fabric  will  be  available  mid-2009  from  the  IBM  al- 
phaworks  site  (http://www.alphaworks.ibm.com/). 

5  Further  Work 

The  Fabric  lays  the  groundwork  for  many  advanced 
features,  and  we  will  actively  extend  its  capabilities  for 
both  field  and  research  use.  As  suitable  new  technolo¬ 
gies  are  created  by  the  ITA  research  programme  we  will 
continue  to  demonstrate  their  application  on  the  Fab¬ 
ric,  with  the  aim  of  providing  them  with  an  accelerated 
route  to  fielded  use.  The  value  of  this  approach  has  al¬ 
ready  been  demonstrated  with  the  distributed/federated 
database  and  policy  technologies  that  are  currently  being 
integrated  into  the  Fabric.  In  particular  we  will  continue 
our  focus  on  the  ITA’s  policy,  security,  and  networking 
technologies.  The  value  of  empirical  feedback  from  prac¬ 
tical  applications  of  the  Fabric  (such  as  the  case  study 
described  above)  has  also  been  observed,  and  we  will 
continue  to  use  this  as  a  source  of  new,  and  refinements 
to  existing,  capabilities.  One  area  of  particular  interest 
is  the  use  of  the  Fabric  on  non-IP  networks,  or  more  typ¬ 
ically,  mixed  IP /non-IP  networks.  We  will  be  targeting 
radio  networks  that  implement  serial  communications: 
point  to  point  or  multi-point  to  point  (i.e. ,  many  sensors 
into  one  node).  The  intention  is  to  deploy  a  full  Fabric 
node  at  the  edge  and  allow  it  to  connect  into  the  bus. 

The  Fabric  is  considered  to  be  a  micro  service  bus. 
We  will  more  fully  develop  its  interfaces  with  the  main¬ 
stream  enterprise  services  bus  technologies  that  form 
the  backbone  of  SOAs.  The  goal  will  be  seamless  pro¬ 
vision  of  edge-of- network  services,  such  as  those  typi¬ 
cally  deployed  on  the  Fabric,  directly  into  the  enter¬ 
prise.  Equally,  we  will  provide  users  at  the  network’s 
edge  with  controlled  access  to  enterprise  services  and 
provide  a  platform  for  the  development  of  novel  solu¬ 
tions  that,  today,  can  be  complex  and  expensive  using 
traditional  techniques.  Note  that  while  such  integration 
is  already  possible  via  the  Fabric,  we  will  be  investigating 


patterns  of  use,  and  identifying  technology  gaps,  towards 

fully  exploiting  this  capability. 
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